fix(replace): apply parent-side foreign key actions during REPLACE - #25089

Codex automated review

The implementation regresses valid REPLACE forms on referenced parent tables by rejecting them instead of applying FK actions.

P1 - Support non-literal and SELECT parent REPLACEs instead of rejecting them (pkg/sql/plan/build_util.go:1216)

genParentSideReplaceFKSqls is invoked for every referenced parent while FK checks are enabled. It rejects REPLACE ... SELECT/TABLE outright at lines 1214-1216, and the later static-literal formatter rejects parameter/function conflict keys (line 1659). Thus valid statements such as PREPARE s FROM 'REPLACE INTO parent VALUES (?, ?)'; and REPLACE INTO parent SELECT ... now fail before execution, even when they produce no conflict. The pre-PR modern REPLACE binder supported these source forms; the added BVT deliberately changes their expected result to not supported. The FK action mechanism needs to consume the evaluated row image (or otherwise preserve these forms), rather than narrowing REPLACE syntax for every table that happens to be referenced.

Two blockers remain. Explicit numeric-zero recognition misses hex and bit zero forms, so autoincrement preprocessing can generate a new key while parent-side FK actions still operate on key zero. Also, non-self-FK input is unconditionally materialized even when the optimistic transaction path bypasses locking, creating O(input) memory and latency. Normalize all exact zero literal forms before both phases and materialize only when the selected execution path requires it.

Two blockers remain. Explicit numeric-zero recognition misses hex and bit zero forms, so autoincrement preprocessing can generate a new key while parent-side FK actions still operate on key zero. Also, non-self-FK input is unconditionally materialized even when the optimistic transaction path bypasses locking, creating O(input) memory and latency. Normalize all exact zero literal forms before both phases and materialize only when the selected execution path requires it.

Codex automated review

The new FK prerequisite locking can deadlock valid concurrent child INSERT and parent REPLACE operations.

P1 - Use the same canonical order for parent REPLACE index locks (pkg/sql/plan/bind_replace.go:917)

The parent path appends unique-index lock targets in tableDef.Indexes order, and performLock acquires targets in that exact slice order. The child path now explicitly sorts its FK locks by parent table and hidden-index name in appendModernChildFkMarkOks. With a parent having two referenced UNIQUE indexes whose definition order is the reverse of their hidden-index-name order, a child INSERT can acquire shared lock A then wait on B while REPLACE acquires exclusive B then waits on A. This creates a transaction deadlock for valid schemas; sort the parent lock targets by the same canonical physical-key order and add a two-FK concurrency regression.

P2 - Remove the obsolete parent-side SQL generator and its disconnected tests (pkg/sql/plan/build_util.go:1195)

genParentSideReplaceFKSqls is no longer called by the production REPLACE path; the head executes actions from the evaluated in-plan old-row stream instead. The 600+ line generator and numerous unit tests now validate a dead SQL-based implementation (including unsupported-shape behavior) rather than executable behavior, adding duplicate FK semantics that will drift. Delete it and replace the tests with assertions/BVTs for the active plan path.

Codex automated review

A referenced nullable unique key still leaves a concurrency hole when the replacement value is statically NULL. Current CI is green; focused local tests could not run because libmo.dylib is absent.

P1 - Lock old unique keys even when the incoming key is NULL (pkg/sql/plan/bind_replace.go:933)

skipUniqueIdx describes the incoming key, but this branch skips the entire index path, including deletion and locking of the matched old index key. For p(id PK, u UNIQUE NULL) with a child FK referencing u, an existing (1,10), and REPLACE INTO p(id) VALUES (1), the replacement conflicts by PK and deletes old u=10, while this plan locks only the base PK because incoming u is NULL. A concurrent child insert can therefore shared-lock hidden index key 10, validate against the still-committed old parent, and commit before the REPLACE transaction commits, leaving an orphan. Separate skipping the new NULL index entry/conflict probe from maintaining and locking a non-NULL old index entry.

Codex automated review

Three blocking correctness/concurrency gaps remain. The latest nullable-unique lock finding is fixed, and current CI is green; focused local tests could not run because libmo.dylib is absent.

P1 - Compose multiple SET NULL actions for the same child row (pkg/sql/plan/build_dml_util.go:930)

The FK loop invokes buildUpdatePlans independently for each SET NULL constraint. For p(id PK), c(id PK, p1, p2) with both p1 and p2 referencing p(id) ON DELETE SET NULL, replacing p(1) builds two full-row images from the original child row: (id,NULL,1) and (id,1,NULL). Updates are implemented as delete-plus-insert, and nothing combines those images into the required (id,NULL,NULL); the UNION machinery also cannot deduplicate different images. This can fail on duplicate writes or preserve one dangling reference. Group all actions for the same child row into one update.

P1 - Lock recursively cascaded rows before processing their dependents (pkg/sql/plan/build_dml_util.go:714)

The root REPLACE correctly locks its old parent rows, but a cascaded child delete puts its exclusive LOCK_OP in one query step while descendant FK checks/actions consume the original unlocked source in sibling steps. With P -> C -> G, T1 can snapshot G, T2 can insert G referencing C and release its shared C lock before T1 requests the exclusive C lock, and T1 can then delete C after its G action already missed the new row. This leaves an orphan. Each recursive level needs the same lock-then-materialize dependency used for the root before scanning or acting on dependents.

P1 - Canonicalize lock order by key within each physical table (pkg/sql/plan/bind_replace.go:1014)

The parent locks each table's new key before its old key, while child FK locks are ordered only by physical table name; equal-table FKs retain declaration order. For p(id PK, u UNIQUE) containing (1,10) and (2,20), REPLACE p VALUES (2,10) can hold key 2 and wait for key 1, while a concurrent child insert with two FKs to p.id and values (1,2) holds key 1 and waits for key 2. This is a lock cycle. Consolidate all keys per physical table and sort/deduplicate the encoded keys consistently on both paths.

Codex automated review

The latest fixes still leave a recursive-cascade deadlock and significant prepared-plan and lock-range regressions.

P1 - Recursive cascade locks use a different canonical order (pkg/sql/plan/build_dml_util.go:510)

Recursive cascades sort base and hidden-index lock targets by TableId, while child FK inserts and parent REPLACE sort hidden targets by IndexTableName. Index table IDs are opaque and can differ from name order (the existing tests deliberately construct this inversion). With P→C→G, a recursive REPLACE can acquire C's hidden index locks in ID order while a concurrent G insert acquires them in name order, producing a lock cycle and timeout. Reuse one canonical comparator for all parent/child/recursive paths and add a multi-index recursive regression.

P2 - FK-sensitive prepared plans rebuild on every EXECUTE (pkg/frontend/computation_wrapper.go:604)

shouldRebuildPreparePlan(false, preparePlan.Plan) is true whenever HasForeignKeyAction is set, so the plan is rebuilt on every EXECUTE rather than only when foreign_key_checks changes. The REPLACE binder sets this flag for any table with FKs or referenced children, and shouldCachePrepareCompile also disables the cached compile. This turns prepared FK-sensitive REPLACE statements into full plan rebuilds per execution; track the setting state or use execution-time gating.

P2 - Multiple FK references force a full parent-range lock (pkg/sql/colexec/lockop/lock_op.go:320)

appendModernChildFkMarkOks emits one shared target per FK. When a child has two FKs referencing the same parent physical namespace, performLock groups them and sets lockTable=true, causing the fetcher to lock the full key domain. A single child insert then conflicts with writes to unrelated parent keys for the transaction lifetime, creating a substantial concurrency and throughput regression. The lock strategy should preserve per-key locking with a deterministic order or otherwise avoid blanket range locking.